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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

[1.28Mcps TDD - Multi-frequency Cell: If multiple frequencies are configured in one cell, the cell is defined as the 
multi-frequency cell.] 

[1.28Mcps TDD - Primary frequency: In a multi-frequency cell, the frequency on which the P-CCPCH is transmitted 
is defined as primary frequency.] 

[1.28Mcps TDD - Secondary frequency: In a multi-frequency cell, any frequency other than the primary frequency is 
defined as secondary frequency.] 

ALCAP: generic name for the transport signalling protocols used to set-up and tear-down transport bearers 

Cell: Radio Network object that can be uniquely identified by a User Equipment from a (cell) identification that is 
broadcasted over a geographical area from one UTRAN Access Point 
A Cell is either FDD or TDD mode. 
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lu: interface between an RNC and an MSC, SGSN or CBC, providing an interconnection point between the RNS and 
the Core Network. It is also considered as a reference point 

lub: interface between the RNC and the Node B 

lur: logical interface between two RNCs 

Whilst logically representing a point to point link between RNCs, the physical realisation need not be a point to point 

link. 

lur-g: logical interface between RNC/BSS and ESS 

Whilst logically representing a point to point link between RNC/BSS and ESS, the physical realisation need not be a 

point to point link. 

Logical Model: Logical Model defines an abstract view of a network or network element by means of information 
objects representing network element, aggregations of network elements, the topological relationship between the 
elements, endpoints of connections (termination points), and transport entities (such as connections) that transport 
information between two or more termination points 

The information objects defined in the Logical Model are used, among others, by connection management functions. In 
this way, a physical implementation independent management is achieved. 

Network sharing supporting UE: as defined in TS 23.251 [28]. 

Network sharing non-supporting UE: as defined in TS 23.251 [28]. 

Node B: logical node in the RNS responsible for radio transmission / reception in one or more cells to/from the UE 
The logical node terminates the lub interface towards the RNC. 

Radio Resources: resources that constitute the radio interface in UTRAN, e.g. frequencies, scrambling codes, 
spreading factors, power for common and dedicated channels 

Node B Application Part: Radio Network SignalUng over the lub 

Radio Network Controller: logical node in the RNS in charge of controlling the use and the integrity of the radio 
resources 

Controlling RNC: role an RNC can take with respect to a specific set of Node B's 

There is only one Controlling RNC for any Node B. The Controlling RNC has the overall control of the logical 

resources of its node B's. 

MBMS Master RNC: role an RNC can take with respect to one or more specific MBSFN cluster(s) 

MRNC may be used for Inter-RNC MBSFN operation whenever dynamic synchronization of radio resources used for 
MBMS services is centrally controlled. There is only one MBMS Master RNC for any MBSFN cluster, which may 
control one or more MBSFN cluster(s). The MRNC has the overall control of the logical resources of the RNSs that are 
used for MBSFN operation within the MBSFN cluster(s). 

Radio Network Subsystem: RNS can be either a full UTRAN or only a part of a UTRAN 

An RNS offers the allocation and release of specific radio resources to establish means of connection in between an UE 
and the UTRAN. A Radio Network Subsystem contains one RNC and is responsible for the resources and 
transmission/reception in a set of cells. 

Serving RNS: role an RNS can take with respect to a specific connection between an UE and UTRAN 

There is one Serving RNS for each UE that has a connection to UTRAN. The Serving RNS is in charge of the radio 

connection between a UE and the UTRAN. The Serving RNS terminates the lu for this UE. 

Drift RNS: role an RNS can take with respect to a specific connection between an UE and UTRAN 

An RNS that supports the Serving RNS with radio resources when the connection between the UTRAN and the UE 

need to use cell(s) controlled by this RNS is referred to as Drift RNS. 

Radio Access Network Application Part: Radio Network Signalling over the lu 

Radio Network Subsystem Application Part: Radio Network Signalling over the lur 
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RRC Connection: point-to-point bi-directional connection between RRC peer entities on the UE and the UTRAN 

sides, respectively 

An UE has either zero or one RRC connection. 

Stand-Alone SMLC: as defined in TS 25.305 [33]. 

User Equipment: Mobile Equipment with one or several UMTS Subscriber Identity Module(s) 

A device allowing a user access to network services via the Uu interface. The UE is defined in ref. TS 23.101 [8]. If this 

term is used in the context of lur-g, it means MS in case it uses radio resources of a DBSS. 

Universal Terrestrial Radio Access Network: UTRAN is a conceptual term identifying that part of the network which 

consists of RNCs and Node Bs between lu an Uu 

The concept of UTRAN instantiation is currently undefined. 

User Datagram Protocol: as defined in IETF RFC 768 [14]. 

UTRAN Access Point: conceptual point within the UTRAN performing radio transmission and reception 

A UTRAN access point is associated with one specific cell, i.e. there exists one UTRAN access point for each cell. It is 

the UTRAN-side end point of a radio link. 

Radio Link: "radio link" is a logical association between a single User Equipment and a single UTRAN access point 
Its physical realisation comprises one or more radio bearer transmissions. 

Radio Link Set: set of one or more Radio Links that has a common generation of Transmit Power Control (TPC) 
commands in the DL 

Uu: Radio interface between UTRAN and the User Equipment 

RAB sub-flows: Radio Access Bearer can be realised by UTRAN through several sub-flows 

These sub-flows correspond to the NAS service data streams that have QoS characteristics that differ in a predefined 

manner within a RAB e.g. different reliability classes. 

RAB sub-flows have the following characteristics: 

1) The sub-flows of a RAB are established and released at the RAB establishment and release, respectively. 

2) The sub-flows of a RAB are submitted and delivered together at the RAB SAP. 

3) The sub-flows of a RAB are carried over the same lu transport bearer. 

4) The sub-flows of a RAB are organised in a predefined manner at the SAP and over the lu interface. The 
organisation is imposed by the NAS as part of its co-ordination responsibility. 

Set of co-ordinated DCHs: set of co-ordinated DCHs is a set of dedicated transport channels that are always 
established and released in combination 

Individual DCHs within a set of co-ordinated DCHs cannot be operated on individually e.g. if the establishment of one 
DCH fails, the establishment of all other DCHs in the set of co-ordinated DCHs shall be terminated unsuccessfully. A 
set of coordinated DCHs is transferred over one transport bearer. All DCHs in a set of co-ordinated DCHs shall have the 
same TTI. 

Shared Network Area (SNA): Area consisting of one or more LA's to which access can be controlled. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAL ATM Adaptation Layer 

AAL2 ATM Adaptation Layer 2 

ALCAP Access Link Control Application Part 

APN Access Point Name 

ATM Asynchronous Transfer Mode 

BM-IWF Broadcast Multicast Interworking Function 

BMC Broadcast/Multicast Control 

BSS Base Station Subsystem 
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CBC Cell Broadcast Centre 

CBS Cell Broadcast Service 

CN Core Network 

CRNC Controlling Radio Network Controller 

DCH Dedicated Channel 

DL Downlink 

DRNS Drift RNS 

DSP Domain Specific Part 

EAB Extended Access Barring 

E-DCH Enhanced UL DCH 

EDGE Enhanced Data rates for Global Evolution 

EACH Forward Access Channel 

FES Eor Further Study 

GERAN GSM EDGE Radio Access Network 

GSM Global System for Mobile Communications 

GTP GPRS Tunnelling Protocol 

GWCN Gateway Core Network 

HPLMN Home PLMN 

IDP Initial Domain Part 

IPv4 Internet Protocol, version 4 

IPv6 Internet Protocol, version 6 

LA Location Area 

MAC Medium Access Control 

MBMS Multimedia Broadcast Multicast Service 

MCCH MBMS point-to-multipoint Control Channel 

MDT Minimization of Drive-Tests 

MOCN Multi Operator Core Network 

MRNC MBMS Master Radio Network Controller 

MSCH MBMS point-to-multipoint Scheduling Channel 

MTCH MBMS point-to-multipoint Traffic Channel 

NACC Network Assisted Cell Change 

NAS Non Access Stratum 

NBAP Node B Application Part 

NNSF NAS Node Selection Fuction 

NSAP Network Service Access Point 

PCH Paging Channel 

PLMN Public Land Mobile Network 

PTM Point To Multipoint 

PTP Point To Point 

QoS Quality of Service 

RAB Radio Access Bearer 

RACH Random Access Channel 

RANAP Radio Access Network Application Part 

RET Remote Electrical Tilting 

RIM RAN Information Management 

RNC Radio Network Controller 

RNL Radio Network Layer 

RNS Radio Network Subsystem 

RNSAP Radio Network Subsystem Application Part 

RNTI Radio Network Temporary Identity 

SAB Service Area Broadcast 

SAS Stand-Alone SMLC 

SIPTO Selected IP Traffic Offload 

SMLC Serving Mobile Location Centre 

SNA Shared Network Area 

SRNC Serving Radio Network Controller 

SRNS Serving RNS 

TMA Tower Mounted Amplifier 

TBSS Target BSS 

TEID Tunnel Endpoint Identifier 

TMGI Temporary Mobile Group Identity 

TNL Transport Network Layer 
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TTI Transmission Time Interval 

UDP User Datagram Protocol 

UE User Equipment 

UL Uplink 

UMTS Universal Mobile Telecommunication System 

URA UTRAN Registration Area 

USIM UMTS Subscriber Identity Module 

UTRAN Universal Terrestrial Radio Access Network 



3.3 



Notation 



For the purposes of the present document, the following notations apply: 



[FDD] 



This tagging of a word indicates that the word preceding the tag "[FDD]" applies only to FDD. 
This tagging of a heading indicates that the heading preceding the tag "[FDD]" and the section 
following the heading applies only to FDD. 



[TDD] 



This tagging of a word indicates that the word preceding the tag "[TDD]" applies only to TDD, 
including 3.84Mcps TDD, 7.68Mcps TDD and 1.28Mcps TDD. This tagging of a heading 
indicates that the heading preceding the tag "[TDD]" and the section following the heading applies 
only to TDD, including 3.84Mcps TDD, 7.68Mcps TDD and 1.28Mcps TDD. 



[3.84Mcps TDD] This tagging of a word indicates that the word preceding the tag "[3.84Mcps TDD]" applies only 
to 3.84Mcps TDD. This tagging of a heading indicates that the heading preceding the tag 
"[3.84Mcps TDD]" and the section following the heading applies only to 3.84Mcps TDD. 

[1.28Mcps TDD] This tagging of a word indicates that the word preceding the tag "[1.28Mcps TDD]" applies only 
to 1.28Mcps TDD. This tagging of a heading indicates that the heading preceding the tag 
"[1.28Mcps TDD]" and the section following the heading applies only to 1.28Mcps TDD. 

[7.68Mcps TDD] This tagging of a word indicates that the word preceding the tag "[7.68Mcps TDD]" applies only 
to 7.68Mcps TDD. This tagging of a heading indicates that the heading preceding the tag 
"[7.68Mcps TDD]" and the section following the heading applies only to 7.68Mcps TDD. 

[FDD - ...] This tagging indicates that the enclosed text following the "[FDD - " applies only to FDD. 

Multiple sequential paragraphs applying only to FDD are enclosed separately to enable insertion of 
TDD specific (or common) paragraphs between the FDD specific paragraphs. 

[TDD - ...] This tagging indicates that the enclosed text following the "[TDD - " applies only to TDD 

including 3.84Mcps TDD, 7.68Mcps TDD and 1.28Mcps TDD. Multiple sequential paragraphs 
applying only to TDD are enclosed separately to enable insertion of FDD specific (or common) 
paragraphs between the TDD specific paragraphs. 



[3.84Mcps TDD 



This tagging indicates that the enclosed text following the "[3.84Mcps TDD - " applies only 
to 3.84Mcps TDD. Multiple sequential paragraphs applying only to 3.84Mcps TDD are enclosed 
separately to enable insertion of FDD and TDD specific (or common) paragraphs between the 
3.84Mcps TDD specific paragraphs. 



[1.28Mcps TDD - ...] This tagging indicates that the enclosed text following the "[1.28Mcps TDD - " applies only 
to 1.28Mcps TDD. Multiple sequential paragraphs applying only to 1.28Mcps TDD are enclosed 
separately to enable insertion of FDD and TDD specific (or common) paragraphs between the 
1 .28Mcps TDD specific paragraphs. 

[7.68Mcps TDD - ...] This tagging indicates that the enclosed text following the "[7.68Mcps TDD - " applies only 
to 7.68Mcps TDD. Multiple sequential paragraphs applying only to 7.68Mcps TDD are enclosed 
separately to enable insertion of FDD and TDD specific (or common) paragraphs between the 
7.68Mcps TDD specific paragraphs. 

Message When referring to a message in the specification, the MESSAGE NAME is written with all letters 

in upper case characters followed by the word "message", e.g. RADIO LINK SETUP REQUEST 

message. 
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IE When referring to an information element (IE) in the specification, the Information Element Name 

is written with the first letters in each word in upper case characters and all letters in Italic font 
followed by the abbreviation "IE", e.g. Transport Format Set IE. 

Value of an IE When referring to the value of an information element (IE) in the specification, the "Value" is 
enclosed by quotation marks, e.g. "Abstract Syntax Error (Reject)". 

Frame When referring to a control or data frame in the specification, the CONTROL/DATA FRAME 

NAME is written with all letters in upper case characters followed by the words "control/data 
fi-ame", e.g. EACH FLOW CONTROL control fi-ame. 



General principles 



The general principles guiding the definition of UTRAN Architecture as well as the UTRAN interfaces are the 
following: 

Logical separation of signalling and data transport networks. 

UTRAN and CN functions are fully separated from transports functions. Addressing scheme used in UTRAN 
and CN shall not be tied to the addressing schemes of transport functions. The fact that some UTRAN or CN 
function resides in the same equipment as some transport functions does not make the transport functions part of 
the UTRAN or the CN. 

- [FDD - Macro diversity is fully handled in the UTRAN.] 

Mobility for RRC connection is fully controlled by the UTRAN. 

When defining the UTRAN interfaces the following principles were followed: The functional division across the 
interfaces shall have as few options as possible. 

Interfaces should be based on a logical model of the entity controlled through this interface. 

One Physical Network Element can implement multiple Logical Nodes. 

Transport Network Control Plane is a functional plane in the interfaces protocol structure that is used for the transport 
bearer management. The actual signalling protocol that is in use within the Transport Network Control Plane depends 
on the underlying transport layer technology. The intention is not to specify a new UTRAN specific Application Part for 
the Transport Network Control Plane but to use signalling protocols standardised in other groups (if needed) for the 
applied transport layer technology. 



5 UMTS General architecture 

5.1 Overview 

Figure 1 shows a simplified UMTS architecture with the external reference points and interfaces to the UTRAN. 
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Figure 1 : UMTS Architecture 



5.2 General protocols architecture 

The protocols over Uu and lu interfaces are divided into two structures: 

- User plane protocols 

These are the protocols implementing the actual radio access bearer service, i.e. carrying user data through the 
access stratum. 

- Control plane protocols 

These are the protocols for controlling the radio access bearers and the connection between the UE and the 
network from different aspects (including requesting the service, controlling different transmission resources, 
handover & streamlining etc.). Also a mechanism for transparent transfer of NAS messages is included. 

5.2.1 User plane 

The radio access bearer service is offered from SAP to SAP by the Access Stratum. Figure 2 shows the protocols on the 
Uu and lu interfaces that linked together provide this radio access bearer service. 
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(1 ) The radio interface protocols are defined in documents TS 25.2xx and TS 25.3xx. 

(2) Tiie lu interface protocols are defined in documents TS 25.41 x. 

Figure 2: lu and Uu User plane 
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5.2.2 Control plane 

Figure 3 shows the control plane (signalling) protocol stacks on lu and Uu interfaces. 
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(1 ) The radio interface protocols are defined in documents TS 25.2xx and TS 25.3xx. 

(2) The protocol is defined in documents TS 25.41 x. (Description of lu interface). 

(3) CM,MM,GMM,SM: This exemplifies a set of NAS control protocols between UE and CN. There may be 
different NAS protocol stacks in parallel. The evolution of the protocol architecture for these protocols is 
outside the scope of the present document. 

Figure 3: lu and Uu Control plane 

NOTE: Both the Radio protocols and the lu protocols contain a mechanism to transparently transfer NAS 

messages. 



6 UTRAN Architecture 

The UTRAN consists of a set of Radio Network Subsystems connected to the Core Network through the lu. 

A RNS consists of a Radio Network Controller one or more Node Bs and optionally one SAS. A Node B is connected 
to the RNC through the lub interface. 

A Node B can support FDD mode, TDD mode or dual-mode operation. 

There are three chip-rate options in the TDD mode: 7.68 Mcps TDD, 3.84 Mcps TDD and 1.28 Mcps TDD. Each TDD 
cell supports one of these options. 

A Node B which supports TDD cells can support one chip-rate option only, or more than one option. 

A RNC which supports TDD cells can support one chip-rate option only, or more than one option. 

The RNC is responsible for the Handover decisions that require signalling to the UE. 

A RNC may include a combining/splitting function to support combination/splitting of information streams (see 
subclause 7.2.4.3). 

Inside the UTRAN, the RNCs of the Radio Network Subsystems can be interconnected together through the lur. Iu(s) 
and lur are logical interfaces. lur can be conveyed over direct physical connection between RNCs or virtual networks 
using any suitable transport network. 

The UTRAN architecture is shown in figure 4. 
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Figure 4: UTRAN Architecture 

Regarding the UE positioning method, the RNC may have full internal support for this function and/or may be 
connected to one SAS via the lupc interface. The following picture illustrates the resulting UTRAN architecture when 
the lupc interface is adopted. 
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Figure 4a: UTRAN Architecture with the lupc option 

The RNC may be connected to BSS supporting GERAN lu mode via the lur-g interface. The following picture 
illustrates the UTRAN and GERAN lu mode connection when the lur-g interface is adopted. For 1 .28Mcps TDD, the 
RNC may be connected to BSS supporting GERAN A/Gb mode via the lur-g interface. The figure 4c illustrates the 
UTRAN and GERAN A/Gb mode connection when the lur-g interface is adopted for 1.28Mcps TDD. 
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Figure 4b: UTRAN and GERAN lu mode connection with lur-g 
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Figure 4c: UTRAN and GERAN A/Gb mode connection with lur-g for1.28Mcps TDD 

Each RNS is responsible for the resources of its set of cells. 

For each connection between User Equipment and the UTRAN, One RNS is the Serving RNS. When required, Drift 
RNSs support the Serving RNS by providing radio resources as shown in figure 5. The role of an RNS (Serving or 
Drift) is on a per connection basis between a UE and the UTRAN. 




Figure 5: Serving and Drift RNS 

To support UE mobility between UTRAN and GERAN lu mode, the Serving RNS may be connected to the DBSS and 
vice versa as illustrated in figures 5a and 5b. For 1.28Mcps TDD, to support UE mobility between UTRAN and 
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GERAN A/Gb mode, the Serving RNS may be connected to the TBSS as illustrated in figure 5c. The role of an RNS or 
BSS (Serving or Drift) is on a per connection basis between a UE and the UTRAN/GERAN lu mode, or between a UE 
and the UTRAN /GERAN A/Gb mode for 1.28Mcp TDD. 




Figure 5a: Serving RNS and Drift BSS, GERAN lu mode 




Figure 5b: Serving BSS and Drift RNS, GERAN lu mode 




Figure 5c: Serving RNS and Target BSS, GERAN A/Gb mode 

The UTRAN is layered into a Radio Network Layer and a Transport Network Layer. 

The UTRAN architecture, i.e. the UTRAN logical nodes and interfaces between them, are defined as part of the Radio 
Network Layer. 

For each UTRAN interface (lu, lur, lub, lupc) the related transport network layer protocol and functionality is specified. 
The transport network layer provides services for user plane transport, signalling transport and transport of 
implementation specific O&M. 



£75/ 



3GPP TS 25.401 version 11.1.0 Release 11 



19 



ETSI TS 125 401 V1 1.1.0 (2013-01) 



An implementation of equipment compliant with the specifications of a certain interface shall support the Radio 
Network Layer protocols specified for that interface. It shall also as a minimum, for interoperability, support the 
transport network layer protocols according to the transport network layer specifications for that interface. 

The network architecture of the transport network layer is not specified by 3GPP and is left as an operator issue. 

The equipment compliant to 3GPP standards shall at least be able to act as endpoints in the transport network layer, and 
may also act as a switch/router within the transport network layer. 

For implementation specific O&M signalling to the Node B, only the transport network layer protocols are in the scope 
of UTRAN specifications. 



SBSS 



Radio Ndwork 
Layer 



NodeB 
Manage 
ment 
System 



DBSS 



Transport 
Layer 




Signalling Link 
25.432 



Figure 6: Protocol layering 

Figure 6 illustrates which parts of the transport network layer that may be (but are not mandated to be) configured by 
the operator as transport networks, i.e. the radio network layer provides a destination address, namely: 

Transport network for implementation specific O&M traffic; 

Signalling network for lu, lur, lur-g and lupc; 

Transport network for lub, lur and lu CS user plane connections; 

Transport network for lu PS user plane connections. 

The signalling link for lub signalling as seen by the radio network layer cannot be configured as a network (no address 
provided). 

A transport network for UTRAN may be configured by the operator to be used also for other traffic than UTRAN 
traffic. 
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6.1 UTRAN Identifiers 

6.1.1 PLIVIN Identity 

A Public Land Mobile Network is uniquely identified as define in TS 23.003 [6] subclause 12.1. 

6.1.2 CN Domain Identifier 

A CN Domain Edge Node is identified as defined in TS 23.003 [6] sub-clause 12.2. 

6.1.3 RNC Identifier 

An RNC node is uniquely identified by its RNC Identifier among the nodes in UTRAN and GERAN lu mode as 
defined in TS 23.003 [6] sub-clause 12.3. A BSS node in GERAN lu mode is uniquely identified by its RNC Identifier 
among the nodes in GERAN lu mode and UTRAN. 

6.1 .4 Service Area Identifier 

The Service Area Identifier (SAI) is defined in TS 23.003 [6] sub-clause 12.4. 

6.1.5 Cell Identifier 

The Cell identifier (C-Id) is used to uniquely identify a cell within an RNS/BSS. The Cell-Id together with the identifier 
of the controlling RNC/BSS (CRNC-Id) constitutes the UTRAN/GERAN Cell Identity (UC-Id) and is used to identify 
the cell uniquely within UTRAN/GERAN lu mode. UC-Id or C-Id is used to identify a cell in UTRAN lub and lur 
interfaces or lur-g interface. 

- UC-Id = RNC-Id + C-Id. 

The C-Id is defined by the operator, and set in the RNC/BSS via O&M. The C-Id is set in a Node B by its C-RNC or in 
the GERAN lu mode cell. 

6.1.6 Local Cell Identifier 

The Local Cell identifier is used to uniquely identify the set of resources within a Node B required to support a cell (as 
identified by a C-Id). As a minimum it shall be unique within the Node B, but it is also capable of supporting 
uniqueness within the UTRAN for management system purposes. 

The Local Cell Identifier is used for the initial configuration of a Node B when no C-Id is defined. The Local Cell 
identifier is defined by the operator, and set in both the Node B and its C-RNC via O&M. The relationship between the 
Local Cell Identifier and C-Id is set in the C-RNC via O&M. 

6.1.7 UE Identifiers 

Radio Network Temporary Identities (RNTI) are used as UE identifiers within UTRAN/GERAN lu mode and in 
signalling messages between UE and UTRAN/GERAN lu mode. 



Six types of RNTI exist: 




1) Serving RNC/BSS RNTI 


(s-RNTI); 


2) Drift RNC/BSS RNTI 


(d-RNTI); 


3) Cell RNTI 


(c-RNTI); 


4) UTRAN/GERAN RNTI 


(u-RNTI); 


5) [TDD - DSCH RNTI 


(DSCH-RNTI)]; 


6) HS-DSCHRNTI 


(HS-DSCH RNTI); 
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7) E-DCHRNTI (E-RNTI); 

s-RNTI is used: 

- by UE to identify itself to the Serving RNC/BSS; 

- by SRNC/SBSS to address the UE/MS; 

- by DRNC/DBSS to identify the UE to Serving RNC. 

s-RNTI is allocated for all UEs having a RRC connection, it is allocated by the Serving RNC/BSS and it is 
unique within the Serving RNC/BSS. s-RNTI is reallocated always when the Serving RNC/BSS for the RRC 
connection is changed. 

d-RNTI is used: 

- by serving RNC/BSS to identify the UE to Drift RNC/BSS. 

NOTE: The d-RNTI is never used on Uu. 

d-RNTI is allocated by drift RNC/BSS upon drift UE contexts establishment and it shall be unique within the 
drift RNC/BSS. Serving RNC/BSS shall know the mapping between s-RNTI and the d-RNTIs allocated in Drift 
RNCs/BSSs for the same UE. Drift RNC/BSS shall know the s-RNTI and SRNC-ID related to existing d-RNTI 
within the drift RNC/BSS. 

c-RNTI is used: 

by UE to identify itself to the controlling RNC; 

by controlling RNC to address the UE. 

c-RNTI is allocated by controlling RNC upon UE accessing a new cell. C-RNTI shall be unique within the 
accessed cell. Controlling RNC shall know the d-RNTI associated to the c-RNTI within the same logical RNC 
(if any). 

u-RNTI 

The u-RNTI is allocated to an UE having a RRC connection and identifies the UE within UTRAN/GERAN lu 
mode. 

u-RNTI is composed of: 

- SRNC identity; 

- s-RNTI. 

[TDD - DSCH-RNTI is used:] 

- [TDD - by controlHng RNC to address the UE on the DSCH and USCH] . 

[TDD - DSCH-RNTI is allocated by controlHng RNC upon UE estabHshing a DSCH or USCH channel. DSCH- 
RNTI shall be unique within the cell carrying the DSCH and/or USCH. DSCH-RNTI is used as UE identifier in 
RRC messages concerning DSCH and USCH allocations and is used in both the downlink and uplink. 

HS-DSCH RNTI is used: 

- for the UE specific CRC in HS-SCCH and HS-PDSCH. 

HS-DSCH RNTI is allocated by controlHng RNC upon UE establishing a HS-DSCH channel. HS-DSCH RNTI 
shall be unique within the cell carrying the HS-DSCH. 

E-RNTI is used: 

- for the UE[FDD - /UE group] specific CRC in E-AGCH. 

E-DCH RNTI is allocated by NodeB upon UE establishing an E-DCH channel. E-DCH RNTI allocated to a UE [FDD - 
/UE group] shall be unique within the cell carrying the E-DCH. 
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Each RNC has a unique identifier within the UTRAN part of the PLMN, denoted by RNC identifier (RNC-ID). This 
identifier is used to route UTRAN interface messages to correct RNC. RNC-ID of the serving RNC together with the s- 
RNTI is a unique identifier of the UE in the UTRAN part of the PLMN. 



6.1.7.1 



Usage of RNTI 



u-RNTI is used as a UE identifier for the first cell access (at cell change) when a RRC connection exists for this UE and 
for UTRAN originated paging including associated response messages. RNC-ID is used by Controlling RNC/BSS to 
route the received uplink messages towards the Serving RNC/BSS. 

NOTE: For the initial access a unique core network UE identifier is used. 

c-RNTI is used as a UE identifier in all other DCCH/DTCH common channel messages on air interface. 

6.1 .7a UE Identifiers in GERAN A/Gb mode (1 .28Mcps TDD) 

Radio Network Temporary Identity (RNTI) is used as a UE identifier within UTRAN /GERAN A/Gb mode and in 
signalling messages between UE and UTRAN /GERAN A/Gb mode. One type of RNTI exists: 

- Drift RNTI (D-RNTI) 
The D-RNTI is allocated by the TBSS and is used to identify the UE during a handover via the lur-g interface. 
There is one possible scenario in which the D-RNTI is used: 

a) The serving RAN node is a UTRAN RNC and the target RAN node is a GERAN BSS in A/Gb mode. 

6.1 .8 Identifiers for dedicated resources within UTRAN 



6.1.8.1 



Radio Network Control Plane identifiers 



Each addressable object in each reference point has an application part level identifier. This identifier is allocated 
autonomously by the entity responsible for initiation of the setup of the object. This application part identifier will be 
used as a reference to the object that is setup. Both ends of the reference point shall memorise the AP Identifier during 
the lifetime of the object. Application part identifier can be related to a specific Transport Network identifier and that 
relationship shall also be memorised by both ends. 

Table 1 lists the basic AP level identifiers in each reference point. 

Table 1 : Basic AP level identifiers in each reference point 



Object 


Identifier 


Abbreviation 


Valid for 


Radio Access Bearer 


Radio Access Bearer ID 


RAB-ID 


lu 


Dedicated Transport 
cliannel 


DCH-ID 


DCH-ID 


lur, lub 


[TDD - Downlink Shared 
Channel] 


DSCH-ID 


DSCH-ID 


lur, lub 


[TDD - Uplink Shared 
Channel] 


USCH-ID 


USCH-ID 


lur, lub 



6.1.8.2 



Transport Network Identifiers 



Transport Network identifiers are used in the Transport Network Layer (TNL) to identify the transport bearer and may 
be used in User Plane in the actual data transmission using the transport link. The Transport Network identifier 
identifies the transport link according to the naming conventions defined for the transport link type in question. Both 
ends of the reference point of the concerned TNL shall memorise the Transport Network identifiers during the lifetime 
of the transport link. Each Transport Network identifier can be binded to an Application Part identifier. 

The Transport Network identifiers vary depending on the transport link type. 

Table 2 indicates examples of the identifiers used for different transmission link types. 
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Table 2: Examples of the identifiers used for different transmission link types 



Transmission link type 


Transport Network Identifier 


AAL2 


AAL2 Path ID + CID 


GTP over IP 


IP address + TEID 


UDP over IP 


IP address + UDP port 



The communication of Transport Network identifiers is made in two ways: 

When an ALCAP is used, the transport layer address communicated via the Radio Network Layers protocols (NBAP, 
RNSAP, RANAP...) is a Transport Network Control Plane address and the Transport Network identifiers are 
communicated through this Transport Network Control Plane only. 

When no ALCAP is used, the Transport Network identifiers are directly communicated via the Radio Network Layers 
protocols (NBAP, RNSAP, RANAP...) on all interfaces. 

In both cases, the transport layer address (e.g. IP address) is encapsulated by the Transport Network Layer in the NSAP 
structure as defined in [Annex A of X.213, ISO/IEC 8348 [15], X.213/Amd. 1, ISO/IEC 8348 [16]] transported 
transparently on lub, lur and lu-CS and passed transparently from the Radio Network Layer to the Transport Network 
Layer. The NSAP structure (encapsulation) is only used in order to provide to the TNL explicit identification of the type 
of the TNL address that is being conveyed by the given RNL protocol. It is then the responsibility of the Transport 
Network Layer to interpret this structure (e.g. to determine accordingly if the requested network type is ATM or IP). 

On the lu-PS, the NSAP structure is not used in RANAP but the 'straight IP addressing' shall be used. 

The following scheme depicts the encapsulation of a native IPv6 (IETF RFC 2460 [12]) address in NSAP structure 
when conveyed in RANAP, RNSAP and NBAP. 



Octet 1 



octet 2 



octet 3 



octet 4 



AFI=35 (lANA) 



ICP=0 (embedded IPv6) 



IPv6 (byte 1) 



IPv6 (bytes 2-5) 



IPv6 (bytes 6-9) 



IPv6 (bytes 10-13) 



IPv6 (bytes 14-16) 



0000 0000 



Figure 6A: IPv6 address embedded in NSAP structure in RANAP/RNSAP/NBAP. 

Note 1: The last octet of the DSP (the DSP is the remaining octets after the IDP IETF RFC 4548 [34]) the 
encapsulation of a native IPv6 address in NSAP structure is unspecified. 

Note 2: The encapsulation of a native IPv4 address in NSAP structure when conveyed in RANAP, RNSAP and 

NBAP shall be encoded according to IETF RFC 4548 [34]. The last 13 octets of the DSP are unspecified. 

Note 3: The default values for the unspecified octets are zero. 



6.1.8.3 



Binding Identifier 



Binding Identifier (Binding ID) is used to initialise the linkage between ALCAP and Application Part (RANAP, 
RNSAP, NBAP) identifiers. Binding identifier can be used both in Radio Network Control plane Application Part 
protocols and in Transport Network Control Plane's ALCAP protocol. When no ALCAP is used. Binding ID may also 
be used to carry the UDP port on lub, lur and lu-CS interfaces. 

Binding ID binds the Radio and Transport Network Control plane identifiers together. To ensure maximal independence 
of those two planes, the binding ID should be used only when necessary: Binding ID shall thus be used only in Radio 
Network Control plane Application Part messages in which a new association between the planes is created and in 
ALCAP messages creating new transport bearers. 

Binding ID for each transport bearer shall be allocated before the setup of that transport bearer. 
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The Binding ID is sent on one direction using the Application Part protocol and is return in the other direction by the 
ALCAP protocol. 

When an Application Part procedure with an allocated Binding ID is applied for modifying an existing Radio Network 
User Plane connection, the decision to use the Binding ID (and the ALCAP procedures) shall be done by that end of the 
reference point that decides whether to use the existing transport bearer or to set up a new transport bearer. 

The Binding ID shall already be assigned and tied to a radio application procedure when the first ALCAP message is 
received in a node. 

The association between the connection Id in the Application Part protocol (e.g. identifying a RAB) and the 
corresponding connection Id in the ALCAP protocol (e.g. identifying the AAL2 channel for that RAB) that was created 
with the help of Binding ID shall be memorised by both peers of each reference point for the lifetime of the 
corresponding transport bearer. 

The Binding ID may be released and re-used as soon as both the Application Part procedure and the ALCAP procedure 
that used it are completed in both peers of the reference point. 

Figure 6a illustrates how application instances of the Radio Network Control Plane and instances of the Transport 
Network Plane are linked together through the Binding Identifier in the set-up phase. 
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Step 1 : Application Part AP-1 assigns tlie Binding Identifier and sends a Radio Network Control Plane Set-up 

(Response) message (which of the two messages depends on the involved interface - lu/lur or lub). The 
message contains the originating node Transport layer address and the Binding Identifier. 

Step 2: Among reception of the Radio Network Control Plane Set-up message, the peer entity AP-2 requests 
ALCAP-2 to establish a transport bearer. The Binding Identifier is passed to ALCAP-2. 

Step 3: ALCAP-2 sends an ALCAP Establish Request to the peer entity ALCAP-1 . The message contains the 
Binding Identifier. The Binding Identifier allows correlating the incoming transport connection with the 
Application Part transaction in step 1 . 

Figure 6a: Usage of Binding ID 

Table 3 indicates the binding identifier allocating entity in each interface. 
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Table 3: Binding identifier allocating entity in each interface 



Reference point 


Allocating entity 


Application part message including 
Binding-ID 


lu 


CN 


Request from CN 


lur 


DRNC 


Response to the request from SRNC 


lub 


Node-B 


Response to the request from DRNC 



6.1.9 URA Identity 

The URA identity is used to uniquely identify an URA, which is a specified set of UTRAN and/or GERAN cells. The 
URA identity can be used to indicate to the UE and the SRNC which URA it shall use in case there are multiple URA 
identities broadcast in the cell where the UE is located. 

6.1 .1 Service Identifiers for MBMS 

6.1 .1 0.1 IP Multicast Address and APN 

The IP Multicast Address and an APN are used to enable the routing of MBMS registration requests within the CN. 
These identifiers are transparent to RAN. 

6.1.10.2 TMGI 

The Temporary Mobile Group Identity (TMGI) is used for group notification purposes and is unique within HPLMN. 
TMGI is used at the start of a session and at UE linking to identify an MBMS Bearer Service. 

The structure of TMGI is specified in TS 23.003 [6]. 

6.1.10.3 Session Identifier 

MBMS session Identifier is used to identify one specific session of a MBMS service and is forwarded transparenfly to the 
UE. 

6.1.10.4 MBMS Service Area 

The MBMS Service Area is defined in TS 25.413 [31]. 

The mapping between a MBMS Service Area and a list of cells is set in the RNC via O&M. 

6.1 .1 0.5 MBMS Cell Group Identifier 

The MBMS Cell Group Identifier is defined in TS 25.346 [30] 

6.1 .1 0.6 MBMS UTRAN Cell Group Identifier 

Void. 

6.1 .1 1 Transport Network Identifiers for MBMS 

Transport Network identifiers are used in the Transport Network Layer (TNL) to identify the MBMS transport bearers 
and may be used in User Plane in the actual MBMS data transmission using the transport link. Each MBMS Transport 
Network identifier can be binded to an Application Part identifier. The Application Part identifier over the lu interface 
is the TMGI corresponding to one MBMS Bearer Service. 

The handling of the MBMS Transport Network identifiers is the same as the handling of Transport Network identifiers 
for dedicated resources described in section 6.1.8.2. 
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6.1 .12 Binding Identifiers for MBMS 



Binding identifiers can be used for MBMS both in Radio Network Control plane Application Part protocols and in 
Transport Network Control Plane's ALCAP protocol. When ALCAP is used, Binding Identifiers (Binding ID) are used 
to initialise the linkage between ALCAP and the MBMS Application Part (RNSAP, NBAP) identifiers. When no 
ALCAP is used, the Binding ID may also be used to carry the UDP port on lub and lur interfaces. 

The handling of the MBMS Binding identifiers is the same as the handling of Binding identifiers for dedicated 
resources described in section 6.L8.3. 

6.1 .13 Use of Extended Identifiers 

The use and deployment of extended RNC-ID and extened S-RNTI in deployments is described in Annex A2. 



6.2 Transport Addresses 



The transport layer address parameter is transported in the radio network application signalling procedures that result in 
establishment of transport bearer connections. 

The transport layer address parameter shall not be interpreted in the radio network application protocols and reveal the 
addressing format used in the transport layer. 

The formats of the transport layer addresses are further elaborated in TS 25.414 [9], TS 25.424 [10], TS 25.434 [11], TS 
25.426 [18]. 

6.3 Function Distribution Principles 

For radio resource management functionality, the following principles apply: 

The CRNC owns the radio resources of a cell. 

The SRNC handles the connection to one UE, and may borrow radio resources of a certain cell from the CRNC. 

When used, the MRNC controls the logical resources of the RNSs that are used for MBSFN operation within the 
MBSFN cluster(s). 

Dynamical control of power for dedicated channels, within limits admitted by CRNC, is done by the SRNC. 

Dynamic control on smaller time-scale for some radio links of the UE connection may be done by the Node B. 
This "inner loop" control is controlled by an "outer loop", for which the SRNC has overall responsibility. 

Scheduling of data for dedicated channels is done by the SRNC, while for common channels it is done by the 
CRNC. 

For management of node-internal resources, the following principle apply: 

Each UTRAN node is considered a network element on its own. The knowledge about the equipment of a 
network element is kept within the network element itself and its management system. The node itself always 
manages node-internal resources. 

For transport network resource management, the following principle apply: 

Management of transport network resources belong to the Transport Layer. Mechanisms relevant for the selected 
transport technology are used. No functional split between UTRAN nodes is specified what regards the 
Transport Layer. 

As a general guideline, the UTRAN protocols should be designed in such a way that they minimise the need for a 
DRNC to interpret the user plane frame protocol information other than for the combining/splitting purpose. 
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7 UTRAN Functions description 

7.1 List of functions 

Transfer of User Data. 

Functions related to overall system access control: 

Admission Control; 

Congestion Control; 

- System information broadcasting. 
Radio channel ciphering and deciphering. 
Integrity protection. 

Functions related to mobility: 

- Handover; 

- SRNS Relocation; 

- Paging support; 
Positioning; 

GERAN System Information Retrieval; 
Enhanced SRNS Relocation. 
Functions related to radio resource management and control: 
Radio resource configuration and operation; 
Radio environment survey; 
Combining/splitting control; 
Connection set-up and release; 
Allocation and deallocation of Radio Bearers; 

- [TDD - Dynamic Channel Allocation (DC A)] ; 
Radio protocols function; 

RF power control; 

- [3.84 Mcps TDD and 7.68Mcps TDD - Timing Advance]; 

- [1.28 Mcps TDD - Uplink S ynchronisation] ; 
Radio channel coding; 

Radio channel decoding; 
Channel coding control; 
Initial (random) access detection and handling; 
CN Distribution function for Non Access Stratum messages. 
Synchronisation. 
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Functions related to broadcast and multicast services (see note) (broadcast/multicast interworking function 
BM-IWF). 

NOTE: Only Broadcast is applicable for Release 99. 

Broadcast/Multicast Information Distribution. 

Broadcast/Multicast Flow Control. 

CBS Status Reporting. 

Tracing. 

- MDT. 

Volume reporting. 

NAS Node Selection. 

RAN Information Management. 

MBMS provision. 

MBMS Notification. 

MOCN and GWCN configuration support. 

- SIPTO at lu-PS (optional). 
Explicit Congestion Notification. 



7.2 Functions description 



7.2.0 Transfer of user data 

This function provides user data transfer capability across the UTRAN between the lu and Uu reference points. 

7.2.1 Functions related to overall system access control 

System access is the means by which a UMTS user is connected to the UTRAN in order to use UMTS services and/or 
facilities. User system access may be initiated from either the mobile side, e.g. a mobile originated call, or the network 
side, e.g. a mobile terminated call. 

7.2.1.1 Admission Control 

The purpose of the admission control is to admit or deny new users, new radio access bearers or new radio links (for 
example due to handover). The admission control should try to avoid overload situations and base its decisions on 
interference and resource measurements. The admission control is employed at for example initial UE access, RAB 
assignment/reconfiguration and at handover. These cases may give different answers depending on priority and 
situation. 

The Admission Control function based on UL interference and DL power is located in the Controlling RNC. 

The Serving RNC is performing admission Control towards the lu interface. 

7.2.1.2 Congestion Control 

The task of congestion control is to monitor, detect and handle situations when the system is reaching a near overload or 
an overload situation with the already connected users. This means that some part of the network has run out, or will 
soon run out of resources. The congestion control should then bring the system back to a stable state as seamless as 
possible. 

NOTE: This admission Control function is related to Radio Resources. 
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Congestion control is performed within UTRAN. 

The RNC may trigger EAB as specified in TS 23.060 [36] subclause 5.3.6.4 and TS 23.251 [28] subclause 4.6. 

7.2.1.3 System information broadcasting 

This function provides the mobile station with the Access Stratum and Non Access Stratum information which are 
needed by the UE for its operation within the network. 

The basic control and synchronisation of this function is located in UTRAN. 

7.2.1 .4 MOCN and GWCN configuration support 

In the MOCN configuration only the radio access part of the network is shared. For the MOCN configuration it is 
required that the rerouting function, as described in TS 25.410 [29], is supported. 

In the GWCN configuration, besides shared radio access network, the core network operators also share part of the core 
network, at least MSC and/or SGSN. 

For both the GWCN and MOCN configurations, the RNC carries the selected PLMN-id between network sharing 
supporting UEs and the corresponding CN. 

The network sharing MOCN and GWCN configurations are described in detail in TS 23.251 [28]. 

7.2.2 Radio channel ciphering and deciphering 

This function is a pure computation function whereby the radio transmitted data can be protected against a non- 
authorised third-party. Ciphering and deciphering may be based on the usage of a session-dependent key, derived 
through signalling and/or session dependent information. 

This function is located in the UE and in the UTRAN. 

7.2.3 Functions related to Mobility 

7.2.3.1 Handover 

This function manages the mobility of the radio interface. It is based on radio measurements and it is used to maintains 
the Quality of Service requested by the Core Network. 

Handover may be directed to/from another system (e.g. UMTS to GSM handover). 

The handover function may be either controlled by the network, or independently by the UE. Therefore, this function 
may be located in the SRNC, the UE, or both. 

7.2.3.2 SRNS Relocation 

The SRNS Relocation function coordinates the activities when the SRNS role is to be taken over by another RNS/BSS. 
The SRNS relocation function manages the lu interface connection mobility from an RNS to another RNS/BSS. 
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Figure 7: Serving RNS Relocation 

The SRNS Relocation is initiated by the SRNC. 
This function is located in the RNC and the CN. 



7.2.3.3 



Paging support 



This function provides the capability to request a UE to contact the UTRAN/GERAN lu mode when the UE is in Idle, 
CELL_PCH or URA_PCH/GRA_PCH states (TS 25.331 [7], TR 43.930 [21]). This function also encompasses a 
coordination function between the different Core Network Domains onto a single RRC connection. 

7.2.3.4 Positioning 

This function provides the capability to determine the geographic position and optionally the velocity of a UE. 

7.2.3.5 NAS Node Selection Function 

The optional NAS Node Selection Function (NNSF) enables the RNC to initially assign CN resources to serve a UE and 
subsequently setup a signalling connection to the assigned CN resource. 

The NNSF is described in detail in TS 23.236 [20]. 



7.2.3.6 



Shared Networks Access Control 



The Shared Networks Access Control function allows the CN to request the UTRAN to apply UE specific access 
control to LAs of the UTRAN and LAs of neighbouring networks. 

The Shared Networks Access Control function is based on either whole PLMNs or Shared Network Areas (SNAs). An 
SNA is an area corresponding to one ore more LAs within a single PLMN to which UE access can be controlled. 

In order to apply Shared Networks Access Control for the UTRAN or for a neighbouring system, the UTRAN shall be 
aware of whether the concerned LA belongs to one (or several) SNA(s) or not. 

If access for a specific UE needs to be restricted, the CN shall provide SNA Access Information for that UE. The SNA 
Access Information indicates which PLMNs and/or which SNAs the UE is allowed to access. 

Based on whether the LA belongs to the PLMNs or SNAs the UE is allowed to access, the UTRAN determines if access 
to a certain LA for a certain UE shall be allowed. 
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If access is not allowed, the UTRAN shall request the CN to release existing resources either by initiating lu Release 
Request procedure with cause value "Access Restricted due to Shared Network" or by requesting a relocation with the 
same cause value. 

7.2.3.7 GERAN System Information Retrieval 

In order to provide the UE with system information related to NACC towards a GERAN system - to be used as an 
optimisation - the GERAN System Information Retrieval function allows: 

The source RAN to request GERAN (via CN) to provide this system information. 

The SRNC to request the DRNC (via lur interface) to provide this system information, if available. 

The request and subsequent transfer of the GERAN System Information is performed transparently with the RIM 
function. The RIM function is further described in section 7.2.8. 

7.2.3.8 Enhanced SRNS Relocation 

The Enhanced SRNS Relocation function coordinates the activities when the SRNS role is to be taken over by another 
RNS. The Enhanced SRNS Relocation function manages the lu interface connection mobility from an RNS to another 
RNS. 

The Enhanced SRNS Relocation is initiated by the SRNC. The relocation of the SRNS functionality is prepared via 
RNSAP means. The CN is not informed until the preparation and execution of the relocation has taken place. 

This function is located in the RNC and the CN. 

7.2.3.9 Subscriber Profile ID for RAT/Frequency Priority 

The RRM strategy in UTRAN may be based on user specific information. 

The Subscriber Profile ID for RAT/Frequency Priority (SPID) parameter received by the RNC via the lu interface is an 
index referring to user information (e.g. mobility profile, service usage profile). The information is UE specific and 
applies to all its Radio Bearers. 

This index is mapped by the RNC to locally defined configuration in order to apply specific RRM strategies (e.g. to 
define RRC_IDLE mode priorities and control inter-RAT/inter frequency handover in RRC_CONNECTED mode). 

7.2.4 Functions related to radio resource management and control 

Radio resource management is concerned with the allocation and maintenance of radio communication resources. 
UMTS radio resources must be shared between circuit transfer mode services and packet transfer modes services 
(i.e. Connection-oriented and/or connectionless-oriented services). 

7.2.4.1 Radio resource configuration and operation 

This function performs configures the radio network resources, i.e. cells and common transport channels, and takes the 
resources into or out of operation. 

7.2.4.2 Radio environment survey 

This function performs measurements on radio channels (current and surrounding cells) and translates these 
measurements into radio channel quality estimates. Measurements may include: 

1) Received signal strengths (current and surrounding cells); 

2) Estimated bit error ratios, (current and surrounding cells); 

3) Estimation of propagation environments (e.g. high-speed, low-speed, satellite, etc.); 

4) Transmission range (e.g. through timing information); 
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5) Doppler shift; 

6) Synchronisation status; 

7) Received interference level; 

8) Total DL transmission power per cell. 

This function is located in the UE and in the UTRAN. 

7.2.4.3 Combining/splitting control 

This function controls the combining/splitting of information streams to receive/ transmit the same information through 
multiple physical channels (possibly in different cells) from/ towards a single mobile terminal. 

The UL combining of information streams may be performed using any suitable algorithm, for example: 

• [FDD - based on maximum ratio algorithm (maximum ratio combining)]; 

• [FDD - based on quality information associated to each TBS (selection-combining)]; 

• [TDD - based on the presence/absence of the signal (selection)]. 

[FDD - combining/splitting control should interact with channel coding control in order to reduce the bit error ratio 
when combining the different information streams]. 

In some cases, depending on physical network configuration, there may be several entities which combine the different 
information streams, i.e. there may be combining/splitting at the SRNC, DRNC or Node B level. 

This function is located in the UTRAN. 

7.2.4.4 Connection set-up and release 

This function is responsible for the control of connection element set-up and release in the radio access sub network. 
The purpose of this function is: 

1) To participate in the processing of the end-to-end connection set-up and release; 

2) And to manage and maintain the element of the end-to-end connection, which is located in the radio access sub 
network. 

In the former case, this function will be activated by request from other functional entities at call set-up/release. In the 
latter case, i.e. when the end-to-end connection has already been established, this function may also be invoked to cater 
for in-call service modification or at handover execution. 

This function is located both in the UE and in the RNC. 

7.2.4.5 Allocation and deallocation of Radio Bearers 

This function consists of translating the connection element set-up (resp. release) requests into physical radio channel 
allocation (resp. deallocation) accordingly to the QoS of the Radio Access Bearer. 

This function may be activated during the call since e.g. the user service request may vary, or macro diversity may be 
used. 

This function is located in the CRNC and SRNC. 

7.2.4.6 [TDD - Dynamic Channel Allocation (DCA)] 

DCA is used in the TDD mode. It includes Fast DCA and Slow DCA. Slow DCA is the process of assigning radio 
resources, including time slots, to different TDD cells according to the varying cell load. Fast DCA is the process of 
assigning resources to Radio Bearers, and is related to Admission Control. 
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7.2.4.7 Radio protocols function 

This function provides user data and signalling transfer capability across the UMTS radio interface by adapting the 
services (according to the QoS of the Radio Access Bearer) to the Radio transmission. This function includes amongst 
other: 

Multiplexing of services and multiplexing of UEs on Radio bearers; 

Segmentation and reassembly; 

Acknowledged/Unacknowledged delivery according to the Radio Access Bearer QoS. 

7.2.4.8 RF power control 

This group of functions controls the level of the transmitted power in order to minimise interference and keep the 
quality of the connections. It consist of the following functions: UL Outer Loop Power Control, DL Outer Loop Power 
Control, UL Inner Loop Power Control, DL Inner Loop Power Control, UL Open Loop Power Control and DL Open 
Loop Power Control. 

7.2.4.8.1 UL Outer Loop Power Control 

The UL Outer Loop Power Control located in the SRNC [TDD - except for uplink shared channels where it is located 
in the CRNC] sets the target quality value for the UL Inner Loop Power Control which is located in Node B for FDD 
and 1.28 Mcps TDD and is located in the UE for 3.84 Mcps and 7.68Mcps TDD. It receives input from quality 
estimates of the transport channel. The UL outer loop power control is mainly used for a long-term quality control of 
the radio channel. 

In FDD and 1.28 Mcps TDD this function is located in the UTRAN, in 3.84 Mcps and 7.68 Mcps TDD the function is 
performed in UTRAN and the target quality value is sent to the UE by the SRNC or the CRNC, respectively. 

In FDD and 1 .28 Mcps TDD, if the connection involves both a SRNS and a DRNS the function UL Outer Loop Power 
Control (located in the SRNC [1.28 Mcps TDD - or in the CRNC, respectively]) sets the target quality for the UL Inner 
Loop Power Control function (located in Node B). 

7.2.4.8.2 DL Outer Loop Power Control 

The DL Outer Loop Power Control sets the target quality value for the DL inner loop power control. It receives input 
from quality estimates of the transport channel, measured in the UE. The DL outer loop power control is mainly used 
for a long-term quality control of the radio channel. 

This function is located mainly in the UE, but some control parameters are set by the UTRAN. 

The SRNC, regularly (or under some algorithms), sends the target down link power range based on the measurement 
report from UE. 

7.2.4.8.3 UL Inner Loop Power Control 

The UL Inner Loop Power Control sets the power of the uplink dedicated [TDD - and shared] physical channels. 

In FDD, it is a closed loop process. It receives the quality target from UL Outer Loop Power Control and quality 
estimates of the uplink dedicated physical control channel. The power control commands are sent on the downlink 
dedicated physical control channel to the UE. This function is located in both the UTRAN and the UE. 

In 3.84 Mcps and 7.68 Mcps TDD it is a open loop process, it receives the quality target from the UL Outer Loop 
Power Control and uses the quality target and quality estimates of downlink channels to set the transmit power. This 
function is located in the UE. 

In 1.28 Mcps TDD, it is a closed loop process. It receives the quality target from UL Outer Loop Power Control, and 
quality estimates of the uplink dedicated physical channels as well as physical uplink shared channels, if any. The 
power control commands are sent on the downlink dedicated physical channels and physical downlink shared channels, 
if any, to the UE. This function is located in both the UTRAN and the UE. 
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7.2.4.8.4 DL Inner Loop Power Control 

The DL Inner Loop Power Control sets the power of the downhnk dedicated [TDD - and shared] physical channels. It 
receives the quality target from DL Outer Loop Power Control and quality estimates of the [FDD - downlink dedicated 
physical control channel] [TDD - downlink dedicated physical channels and physical downlink shared channels if any]. 
The power control commands are sent on the [FDD - uplink dedicated physical control channel] [TDD - downlink 
dedicated physical channels and physical downlink shared channels if any] to the UTRAN. 

This function is located in both the UTRAN and the UE. 

7.2.4.8.5 UL Open Loop Power Control 

The UL Open Loop Power Control sets the initial power of the UE, i.e. at random access. The function uses UE 
measurements and broadcasted cell/system parameters as input. 

This function is located in both the UTRAN and the UE. 

7.2.4.8.6 DL Open Loop Power Control 

The DL Open Loop Power Control sets the initial power of downlink channels. It receives downlink measurement 
reports from the UE. 

This function is located in both the UTRAN and the UE. 

7.2.4.9 Radio channel coding 

This function introduces redundancy into the source data flow, increasing its rate by adding information calculated from 
the source data, in order to allow the detection or correction of signal errors introduced by the transmission medium. 
The channel coding algorithm(s) used and the amount of redundancy introduced may be different for the different types 
of logical channels and different types of data. 

This function is located in both the UE and in the UTRAN. 

7.2.4.10 Radio channel decoding 

This function tries to reconstruct the source information using the redundancy added by the channel coding function to 
detect or correct possible errors in the received data flow. The channel decoding function may also employ a priori error 
likelihood information generated by the demodulation function to increase the efficiency of the decoding operation. The 
channel decoding function is the complement function to the channel coding function. 

This function is located in both the UE and in the UTRAN. 

7.2.4.1 1 Channel coding control 

This function generates control information required by the channel coding/ decoding execution functions. This may 
include channel coding scheme, code rate, etc. 

This function is located in both the UE and in the UTRAN. 

7.2.4.12 Initial (random) access detection and handling 

This function will have the ability to detect an initial access attempt from a mobile station and will respond 
appropriately. The handling of the initial access may include procedures for a possible resolution of colliding attempts, 
etc. The successful result will be the request for allocation of appropriate resources for the requesting mobile station. 

This function is located in the UTRAN. 
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7.2.4.13 CN Distribution function for Non Access Stratum messages 

In the RRC protocol, messages from the NAS shall be transparently transferred within the Access Stratum using the 
Direct Transfer procedure. A distribution function in the UE and the SRNC shall handle the CN domain indicator being 
part of the AS message to direct messages to the appropriate NAS entity i.e. the appropriate Mobility Management 
instance in the UE domain and the appropriate CN domain. 

In the downlink direction the UE shall be provided by the SRNC with the information on the originating CN domain for 
the individual NAS message. 

In the uplink direction, the process performed by the distribution function in the UE consists in inserting the appropriate 
values for the CN domain indicator in the AS message and the process performed by the SRNC consists in evaluating 
the CN domain indicator contained in the AS message and distribute the NAS message to the corresponding RANAP 
instance for transfer over lu interface. 

This distribution function is located in both the UE and in the SRNC. 

7.2.4.14 [3.84 Mcps and 7.68 Mcps TDD - Timing Advance] 

This function is used in uplink to align the uplink radio signals from the UE to the UTRAN. Timing Advance is based 
on uplink burst timing measurements performed by the Node B LI, and on Timing Advance commands sent downlink 
to the UE. 

7.2.4.15 Service specific function for Non Access Stratum messages 

A service specific function in the UE provides a SAP for a particular service (e.g. a given priority). In the downlink 
direction, the SRNC may base the routing on this SAP. 

This service specific function is located in both the UE and the SRNC. 

7.2.4.1 6 [1 .28 Mcps TDD - Uplink Synchronisation] 

This function is used in uplink to synchronise the uplink radio signals from the UE to the UTRAN. At the detection of 
uplink burst, the Node B will evaluate the received power level and timing, and reply by sending the adjustment 
information to UE to modify its timing and power level for next transmission and for establishment of the Uplink 
synchronisation procedure. 

7.2.5 Functions related to broadcast and multicast services 
(broadcast/multicast interworking function BM-IWF) 

See note. 

7.2.5.1 Broadcast/Multicast Information Distribution 

The broadcast/multicast information distribution function distributes received CBS messages towards the BMC entities 
configured per cell for further processing. The distribution of broadcast/multicast information relate on the mapping 
between service area and cells controlled by the RNC. The provision of this mapping information is an O&M function. 

NOTE: Only Broadcast is applicable for Release 99. 

7.2.5.2 Broadcast/Multicast Flow Control 

When processing units of the RNC becomes congested, the Broadcast/Multicast Flow Control function informs the data 
source about this congestion situation and takes means to resolve the congestion. 

7.2.5.3 CBS Status Reporting 

The RNC collects status data per cell (e.g. No-of-Broadcast-Completed-List, Radio-Resource-Loading-List), and 
matches these data to Service Areas. The status data is transmitted to the CBC, if a query has been made by the CBC. 
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7.2.6 Tracing 

This function allows tracing of various events related to the UE and its activities. 

7.2.7 Volume Reporting 

The data volume reporting function is used to report the volume of unacknowledged data to the CN for accounting 
purpose. 

7.2.8 RAN Information Management 

The RAN Information Management (RIM) function is a generic mechanism that allows the request and transfer of 
information between two RAN nodes e.g. GERAN System information. The RIM mechanism allows to start, stop and 
resume both on demand and on event transfer of information. RIM also provides native error handling function at RIM 
level and at RIM appHcation level. The RIM function is further described in TR 44.901 [22] and TS 48.018 [23]. 

7.2.9 Functions related to MBMS 

7.2.9.1 MBMS provision 

The MBMS provision enables the RNC to provide a multicast service via an optimised transmission of the MBMS 
bearer service in UTRAN via techniques such as PTM transmission, selective combining. Soft Combining and 
transmission mode selection between PTM and FTP bearer. 

The MBMS provision enables the RNC to provide a broadcast service via a PTM transmission bearer. 

7.2.9.2 MBMS Notification Coordination 

The characteristic of MBMS implies a need for MBMS notification co-ordination i.e. specific handling of MBMS 
Notification when UE is in Cell-DCH state. MBMS notification co-ordination is performed by UTRAN when the 
session is ongoing. The TMGI is used for coordination. 

The MBMS functions are further described in TS 25.346 [30]. 

7.2.10 SIPTOatlu-PS 

If supported, SIPTO at lu- PS Function provides the capability to offload certain PS RABs from the CN at RAB setup. 
The SIPTO at lu-PS is implementation dependent and may be implemented in a separate entity outside of RNS, for 
further information see TS 23.060 [36]. 



7.2.1 1 Explicit Congestion Notification 



The RNC and the UE support of the Explicit Congestion Notification (ECN) is specified in Section 5 of IETF RFC 
3168 [37] (i.e., the normative part of IETF RFC 3168 [37] that applies to the end-to-end flow of IP packets), and below. 
This enables the RNC to control the initial codec rate selection and/or to trigger a codec rate reduction. Thereby the 
RNC can increase capacity (e.g., in terms of number of accepted VoIP calls), and improve coverage (e.g. for high bit 
rate video sessions). 

The RNC should set the Congestion Experienced (CE) codepoint ('11') in PDCP SDUs in the downlink direction to 
indicate downlink (radio) congestion if those PDCP SDUs have one of the two ECN-Capable Transport (ECT) 
codepoints set. 

The RNC should set the Congestion Experienced (CE) codepoint ('11') in PDCP SDUs in the uplink direction to 
indicate uplink (radio) congestion if those PDCP SDUs have one of the two ECN-Capable Transport (ECT) codepoints 
set. 

7.2.12 MDT 

This function allows to activate and handle MDT sessions by trace procedure as described in TS37.320 [38]. 
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8 Mobility IVIanagement 

8.1 Signalling connection 

Based on TS 23. 1 10 [2], the UE may either have or not have a signalhng connection: 

1) When a signalhng connection exists that is established over the Dedicated Control Service Access Point (DC- 
SAP) from the Access Stratum. 

Therefore, the CN can reach the UE by the dedicated connection SAP on the CN side, and the UTRAN has a 
context with the UE and CN for this particular connection. This context is erased when the connection is 
released. The dedicated connection can be initiated from the UE only. 

NOTE: A dedicated connection is currently defined as Signalling Connection in TS 23. 110 [2]. Note that in the 
radio interface, dedicated or common channels can be used. 

Depending on the activity of a UE, the location of the UE is known either on cell level (higher activity) or in a 
larger area consisting of several cells (lower activity). This will (i) minimise the number of location update 
messages for moving UEs with low activity and (ii) remove the need for paging for UEs known on cell level. 

2) When a dedicated connection does not exist, the CN must reach the UE via the Notification SAP. The message 
sent to the UE can be a request to the UE to establish a dedicated connection. The UE is addressed with a 
user/terminal identity and a "geographical area". 

8.2 Consequences for Mobility Handling 

It is generally agreed to contain radio access specific procedures within UTRAN. This means that all cell level mobility 
should be handled within UTRAN. Also the cell structure of the radio network should not necessarily be known outside 
the UTRAN. 

When there exists a dedicated connection to the UE, the UTRAN shall handle the radio interface mobility of the UE. 
This includes procedures such as soft handover, and procedures for handling mobility in the CELL_PCH and 
URA_PCH/GRA_PCH state TS 25.331 [7]. 

When a dedicated connection between the UTRAN and the UE does not exist, no UE information is needed in UTRAN. 
Therefore, the mobility is handled directly between UE and CN outside access stratum (e.g. by means of registration 
procedures). When paging the UE, the CN indicates a 'geographical area' that is translated within UTRAN to the actual 
cells that shall be paged. A 'geographical area' shall be identified in a cell-structure independent way. One possibility is 
the use of 'Location Area identities'. 

During the lifetime of the dedicated connection, the registrations to the CN are suppressed by the UE. When a dedicated 
connection is released, the UE performs a new registration to the CN, when needed. 

Thus, the UTRAN does not contain any permanent 'location registers' for the UE, but only temporary contexts for the 
duration of the dedicated connection. This context may typically contain location information (e.g. current cell(s) of the 
UE) and information about allocated radio resources and related connection references. 



9 Synchronisation 

9.1 SYNCHRONISATION MODEL 

Different synchronisation issues are identified within UTRAN, i.e.: 
Network Synchronisation; 
Node Synchronisation; 
- Transport Channel synchronisation; 
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Radio Interface Synchronisation; 

Time Alignment handling. 

The Nodes involved by the above mentioned synchronisation issues (with exception of Network and Node 
Synchronisation) are shown by the Synchronisation Issues Model of figure 8. Further details of synchronisation are in 

TS 25.402 [5]. 
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Figure 8: Synchronisation issues model 



10 UTRAN O&M Requirements 
10.1 O&M of Node B 

The O&M of Node B is separated in two parts: the O&M linked to the actual implementation of Node B, denoted as 
Implementation Specific O&M, and the O&M which impacts on the traffic carrying resources in Node B controlled 
from the RNC, denoted logical O&M. The RNS architecture with the O&M interfaces is shown in figure 9. 
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NOTE 1: 



Figure 9: RNS architecture with O&IV! interfaces 

The concept of an interface from the RNC to the management system is shown for clarity only. It's 
definition is outside the scope of 3GPP-TSG-RAN-WG3. 



NOTE 2: The presentation of the O&M functions within the management system is shown for clarity only. Their 
actual implementation is outside the scope of 3GPP-TSG-RAN-WG3. 

NOTE 3: The standardisation of the Implementation Specific O&M is outside the scope of 3GPP-TSG-RAN-WG3. 
The 3GPP-TSG-RAN-WG3 should only address the bearer for the Implementation Specific O&M. 

NOTE 4: The figure shows only logical connections and does not intend to mandate any physical interfaces. 

NOTE 5: The luant interface to the control unit of the RET antennas or TMAs is specified in the series of Technical 
Specifications 25.460 [24], 25.461 [25], 25.462 [26] and 25.466 [32]. An Implementation Specific O&M 
function is needed for the RET antennas or TMAs control to translate the control signalling from the 
Node B Element Manager into the control commands of the luant interface specified in TS 25.460 [24]. 

1 0.1 .1 Implementation Specific O&M 

The Implementation Specific O&M functions are heavily dependent on the implementation of Node B, both for its 
hardware components and for the management of the software components. It needs therefore to be implementation 
dependent, and be performed between Node B and the management system. 

One solution for the transport of Implementation Specific O&M is to route from Node B to the management system via 
the RNC. In this case, the Implementation Specific O&M interface and lub interface share the same physical bearer, and 
TS 25.442 [4] specifies the routing function and the transport bearer for this scenario. The deployment of the routing 
across the RNC in the UTRAN is optional. Where signalling between co-located equipment and its management system 
is required, this may be carried over the same bearer as Implementation Specific O&M. 

10.1.2 Logical O&M 

Logical O&M is the signalling associated with the control of logical resources (channels, cells, . . .) owned by the RNC 
but physically implemented in the Node B. The RNC controls these logical resources. A number of O&M procedures 
physically implemented in Node B impact on the logical resources and therefore require an information exchange 
between RNC and Node B. All messages needed to support this information exchange are classified as Logical O&M 
forming an integral part of NB AP. 
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11 



UTRAN Interfaces 



11.1 General Protocol Model for UTRAN Interfaces 
11.1.1 General 

The general protocol model for UTRAN Interfaces is depicted in figure 10, and described in detail in the following 
subclauses. The structure is based on the principle that the layers and planes are logically independent of each other. 
Therefore, as and when required, the standardisation body can easily alter protocol stacks and planes to fit future 
requirements. 
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Figure 10: General Protocol Model for UTRAN Interfaces 

11.1.2 Horizontal Layers 

The Protocol Structure consists of two main layers. Radio Network Layer, and Transport Network Layer. All UTRAN 
related issues are visible only in the Radio Network Layer, and the Transport Network Layer represents standard 
transport technology that is selected to be used for UTRAN, but without any UTRAN specific requirements. 

11.1.3 Vertical Planes 



11.1.3.1 



Control Plane 



The Control Plane Includes the Application Protocol, i.e. RANAP, RNSAP or NBAP, and the Signalling Bearer for 
transporting the Application Protocol messages. 

Among other things, the Application Protocol is used for setting up bearers for (i.e. Radio Access Bearer or Radio Link) 
in the Radio Network Layer. In the three plane structure the bearer parameters in the Application Protocol are not 
directly tied to the User Plane technology, but are rather general bearer parameters. 

The Signalling Bearer for the Application Protocol may or may not be of the same type as the Signalling Protocol for 
the ALCAP. The Signalling Bearer is always set up by O&M actions. 
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11.1.3.2 



User Plane 



The User Plane Includes the Data Stream(s) and the Data Bearer(s) for the Data Stream(s). The Data Stream(s) is/are 
characterised by one or more frame protocols specified for that interface. 

11.1 .3.3 Transport Network Control Plane 

The Transport Network Control Plane does not include any Radio Network Layer information, and is completely in the 
Transport Layer. It includes the ALCAP protocol(s) that is/are needed to set up the transport bearers (Data Bearer) for 
the User Plane. It also includes the appropriate Signalling Bearer(s) needed for the ALCAP protocol(s). 

The Transport Network Control Plane is a plane that acts between the Control Plane and the User Plane. The 
introduction of Transport Network Control Plane is performed in a way that the Application Protocol in the Radio 
Network Control Plane is kept completely independent of the technology selected for Data Bearer in the User Plane. 
Indeed, the decision to actually use an ALCAP protocol is completely kept within the Transport Network Layer. 

It should be noted that ALCAP might not be used for all types Data Bearers. If there is no ALCAP signalling 
transaction, the Transport Network Control Plane is not needed at all. This is the case when pre-configured Data 
Bearers are used or when the IP (IETF RFC 791 [17]) UTRAN option is used between two IP UTRAN nodes or 
between an IP UTRAN node and an IP CN node. 

When Transport Network Control Plane is used, the transport bearers for the Data Bearer in the User Plane are set up in 
the following fashion. First there is a signalling transaction by the Application Protocol in the Control Plane, which 
triggers the set up of the Data Bearer by the ALCAP protocol that is specific for the User Plane technology. 

The following interworking alternatives are specified for the IP-ATM interworking: 

1) ATM/IP Dual Stack supported in the IP UTRAN node. When an ATM/IP dual stack is implemented in the IP 
UTRAN node, support of an IP ALCAP protocol is not required. 

Annex A of TS 25.414 [9] shows an example of protocols for the case the ATM&IP UTRAN/CN-node has no ATM 
connectivity. 
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2) An Interworking Function (IWF), either internal or external to the UTRAN/CN node. 

Annex A of TS 25.414 [9] shows an example of a protocol stack for the case when the IWF is an external unit to the 
UTRAN/CN node. Other protocol stacks for this case are not precluded. 
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11.1 .3.4 Transport Network User Plane 

The Data Bearer(s) in the User Plane, and the Signalling Bearer(s) for Application Protocol, belong also to Transport 
Network User Plane. As described in the previous subclause, the Data Bearers in Transport Network User Plane are 
directly controlled by Transport Network Control Plane during real time operation, but the control actions required for 
setting up the Signalling Bearer(s) for Application Protocol are considered O&M actions. 
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1 1 .2 Protocol Model (Informative) 



The following subclause is a informative subclause which aim is to provide an overall picture of how the MAC layer is 
distributed over Uu, lub and lur for the RACH, FACH, DCH, [TDD - DSCH, USCH] and HS-DSCH. 

1 1 .2.1 RACH Transport Channel 

Figure 1 1 shows the protocol stack model for the RACH transport channel when the Controlling and Serving RNC are 
co-incident. 

For the RACH transport channel, Dedicated MAC (MAC-d) uses the services of Common MAC (MAC-c/sh). 



DTCH DCCH CCCH 



CCCH DCCH DTCH 















' 






MAC-d 


















MAC-d 


MAC-c/sh 














MAC-c/sh 








PHY 


PHY 


RachFP 


RachFP 


TNL 


TNL 































UE Uu NodeB lub CRNC/SRNC 

Figure 11: RACH: Coincident Controlling and Serving RNC 

The Common MAC (MAC-c/sh) entity in the UE transfers MAC-c/sh PDU to the peer MAC-c/sh entity in the RNC 
using the services of the Physical Layer. 

An Interworking Function (IWF) in the Node B interworks the RACH frame received by the PHY entity into the RACH 
Frame Protocol (RACH FP) entity. 

The RACH Frame Protocol entity adds header information to form a RACH FP PDU that is transported to the RNC 
over a transport bearer. 

At the RNC, the RACH FP entity dehvers the MAC-c/sh PDU to the MAC-c/sh entity. 

Figure 12 shows the protocol model for the RACH transport channel with separate Controlling and Serving RNC. In 
this case, lur RACH Frame Protocol (RACH FP) is used to interwork the Common MAC (MAC-c/sh) at the Controlling 
RNC with the Dedicated MAC (MAC-d) at the Serving RNC. 
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Figure 12: RACH: Separate Controlling and Serving RNC 

1 1 .2.2 CPCH [FDD] Transport Channel 

Void. 

1 1 .2.3 FACH Transport Channel 

Figure 15 shows the protocol model for the FACH transport channel when the Controlling and Serving RNC are co- 
incident. 
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Figure 15: FACH Co-incident Controlling and Serving RNC 

The Common MAC (MAC-c/sh/m) entity in the RNC transfers MAC-c PDU to the peer MAC-c entity in the UE using 
the services of the FACH Frame Protocol (FACH FP) entity. 

The FACH Frame Protocol entity adds header information to form a FACH FP PDU which is transported to the Node B 
over a transport bearer. 

An Interworking Function (IWF) in the Node B interworks the FACH frame received by FACH Frame Protocol (FACH 
FP) entity into the PHY entity. 

FACH scheduling is performed by MAC-c/sh/m in the CRNC. 
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Figure 16 shows the protocol model for the FACH transport channel with separate Controlling and Serving RNC. In this 
case, lur FACH Frame Protocol is used to interwork the Common MAC (MAC-c) at the Controlling RNC with the 
Dedicated MAC (MAC-d) at the Serving RNC. 



DTCH DCCH MTCH MCCH 

I Imsch 

CCCH 



MTCH MCCH 



Figure 16: FACH: Separate Controlling and Serving RNC 



1 1 .2.4 DCH Transport Channel 
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Figure 17 shows the protocol model for the DCH transport channel when the Controlling and Serving RNC are co- 
incident. 
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Figure 17: DCH: Co-incident Controlling and Serving RNC 

The DCH transport channel introduces the concept of distributed PHY layer. 

An Interworking Function (IWF) in the Node B interworks between the DCH Frame Protocol (DCH FP) entity and the 
PHY entity. 



£75/ 



3GPP TS 25.401 version 11.1.0 Release 11 



45 



ETSI TS 125 401 V1 1.1.0 (2013-01) 



DTCH DCCH 



DCCH DTCH 



I 1 












[ 


MAC-d 












MAC-d 


PHY-upper 










PHY 




PHY 










PHY 


DchFP 






DchFP 


DchFP 






DchFP 


PHY 


TNL 


TNL 


TNL 


TNL 

























UE 



Uu NodeB lub CRNC lur 

Figure 18: DCH: Separate Controlling and Serving RNC 



SRNC 



Figure 18 shows the protocol model for the DCH transport channel with separate Controlling and Serving RNC. In this 
case, the lub DCH FP is terminated in the CRNC and interworked with the lur DCH FP through a PHY function. This 
function performs optional soft handover or can be a null function. 

1 1 .2.5 DSCH Transport Channel [TDD] 

Figure 19 shows the protocol model for the DSCH transport channel when the Controlling and Serving RNC are co- 
incident. 
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Figure 19: DSCH Co-incident Controlling and Serving RNC 

The Shared MAC (MAC-c/sh) entity in the RNC transfers MAC-c/sh PDU to the peer MAC-c/sh entity in the UE using 
the services of the DSCH Frame Protocol (DSCH FP) entity. The DSCH FP entity adds header information to form a 
DSCH FP PDU that is transported to the Node B over a transport bearer. 

An Interworking Function (IWF) in the Node B interworks the DSCH frame received by DSCH FP entity into the PHY 
entity. DSCH scheduling is performed by MAC-c/sh in the CRNC. 

Figure 20 shows the protocol model for the DSCH transport channel with separate Controlling and Serving RNC. In this 
case, lur DSCH Frame Protocol is used to interwork the MAC-c/sh at the Controlling RNC with the MAC-d at the 
Serving RNC. 
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Figure 20: DSCH: Separate Controlling and Serving RNC 



1 1 .2.6 USCH Transport Channel [TDD] 



Figure 21 shows the protocol model for the USCH transport channel when the Controlling and Serving RNC are co- 
incident. 
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Figure 21 : USCH Co-incident Controlling and Serving RNC 

The Shared MAC (MAC-c/sh) entity in the RNC receives MAC-c/sh PD\] from the peer MAC-c/sh entity in the UE 
using the services of the Interworking Function in the Node B, and the USCH Frame Protocol (USCH FP) entity. The 
USCH FP entity in the Node B adds header information to form a USCH FP PDU that is transported to the RNC over a 
transport bearer. 

An Interworking Function (IWF) in the Node B interworks the received USCH PHY entity into an USCH frame to be 
transmitted by the USCH FP entity over the lub interface. USCH scheduling is performed by MAC-c/sh in UE and by 
C-RRC in the CRNC. 

Figure 22 shows the protocol model for the USCH transport channel with separate Controlling and Serving RNC. In this 
case, lur USCH Frame Protocol is used to interwork the MAC-c/sh at the Controlling RNC with the MAC-d at the 
Serving RNC. 
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Figure 22: USCH: Separate Controlling and Serving RNC 



1 1 .2.7 HS-DSCH Transport Channel 



Figure 23 shows the protocol model for the HS-DSCH transport channel when the Controlling and Serving RNC are co- 
incident. [FDD and 1 .28 Mcps TDD - The protocol model in Figure 23 is applied for HS-DSCH configured for UEs in 
CelLDCH.] 
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Figure 23: HS-DSCH Co-incident Controlling and Serving RNC 

The High Speed MAC (MAC-hs) or Enhanced High Speed MAC (MAC-ehs) entity in the Node B transfers MAC-hs 
(or MAC-ehs) PDU to the peer MAC-hs (or MAC-ehs) entity in the UE over the Uu interface. The Dedicated MAC 
(MAC-d) entity in the RNC transfers MAC-d PDUs to the MAC-hs or MAC-ehs in the Node B using the services of the 
HS-DSCH Frame Protocol (HS-DSCH FP) entity. The HS-DSCH FP entity adds header information to form a HS- 
DSCH FP PDU that is transported to the Node B over a transport bearer. 

A Relaying Function in the Node B relays the HS-DSCH frame received by HS-DSCH FP entity to the MAC-hs (or 
MAC-ehs) entity. HS-DSCH scheduling is performed by MAC-hs (or MAC-ehs) in the Node B. 

Figure 24 shows the protocol model for the HS-DSCH transport channel with separate Controlling and Serving RNC. 
[FDD and 1 .28 Mcps TDD - The protocol model in Figure 24 is applied for HS-DSCH configured for UEs in 
Cell_DCH.] In this case, lur HS-DSCH Frame Protocol is used to interwork the Flow Control function at the 
Controlling RNC with the MAC-d at the Serving RNC. Also in this case, lub HS-DSCH Frame Protocol is used to 
interwork the MAC-hs (or MAC-ehs) at the Node B with the Flow Control function at the Controlling RNC. 
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Figure 24: HS-DSCH: Separate Controlling and Serving RNC (configuration with CRNC flow control) 

Figure 25 shows the protocol model for the HS-DSCH transport channel with the Controlling RNC user plane RNL 
being bypassed. [FDD and 1 .28 Mcps TDD - The protocol model in Figure 25 is applied for HS-DSCH configured for 
UEs in CelLDCH.] In this case, the CRNC does not have any user plane RNL function for the HS-DSCH. MAC-d in 
SRNC is located directly above MAC-hs (or MC-ehs) in Node B, i.e. in the HS-DSCH user plane RNL, the SRNC is 
directly connected to the Node B, thus bypassing the CRNC user plane RNL. The CRNC performs only user plane TNL 
functions. 
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Figure 25: HS-DSCH: Serving RNC with bypassed Controlling RNC (configuration without CRNC flow 

control) 

[FDD and 1.28 Mcps TDD - Figure 25 A shows the protocol model for the HS-DSCH transport channel configured for 
UE in CelLFACH, Cell_PCH and URA_PCH, when the Controlhng and Serving RNC are co-incident. 

The Common MAC (MAC-c/sh/m) entity in the RNC transfers MAC-c PDU to the peer MAC-c entity in the UE using 
the services of the HS-DSCH Frame Protocol (HS-DSCH FP) entity. 

The HS-DSCH Frame Protocol entity adds header information to form a HS-DSCH FP PDU which is transported to the 
Node B over a transport bearer. 
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The Enhanced High Speed MAC (MAC-ehs) entity in the Node B transfers MAC-ehs PDU to the peer MAC-ehs entity 
in the UE over the Uu interface. ] 



DTCH DCCH 
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TNL 
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Figure 25A: HS-DSCH configured for UE in Cell_FACH, Cell_PCH and URA_PCH: Co-incident 
Controlling and Serving RNC (FDD and 1.28 Mcps TDD only) 

[FDD and 1 .28 Mcps TDD - Figure 25B shows the protocol model for the HS-DSCH transport channel configured for 
UE in CelLFACH, Cell_PCH and URA_PCH, with separate Controlling and Serving RNC. In this case, lur HS-DSCH 
Frame Protocol is used to interwork the Flow Control function at the MAC-c at Controlling RNC with the MAC-d at 
the Serving RNC. Also in this case, lub HS-DSCH Frame Protocol is used to interwork the MAC-ehs at the Node B 
with the Flow Control function at the MAC-c at the Controlling RNC] 
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Figure 25B: HS-DSCH configured for UE in Cell_FACH, Cell_PCH and URA_PCH: Serving RNC with 
Separate Controlling and Serving RNC (FDD and 1.28 Mcps TDD only) 
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1 1 .2.8 E-DCH Transport Channel 



Figure 26 shows the protocol model for the E-DCH transport channel when the Controlling and Serving RNC are co- 
incident. [FDD and 1 .28 Mcps TDD - The protocol model in Figure 26 is applied for E-DCH configured for UEs in 
CelLDCH.] 
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Figure 26: E-DCH Co-incident Controlling and Serving RNC 

The E-DCH MAC (MAC-e/MAC-es)/Enhanced E-DCH MAC (MAC-i/MAC-is) entity in the UE transfers MAC-e 
/MAC-i PDUs to the peer MAC-e/MAC-i entity in the Node B and MAC-es/MAC-is PDUs to the peer MAC-es /MAC- 
is entity in the RNC using the services of the Physical Layer. 

The E-DCH FP entity adds header information to form a E-DCH FP PDU that is transported to the RNC over a 
transport bearer. 

An Interworking Function (IWF) in the Node B interworks the E-DCH frame received by the MAC-e/MAC-i entity into 
the E-DCH Frame Protocol (E-DCH FP) entity. E-DCH scheduling is performed by MAC-e/MAC-i in the Node B and 
reordering is performed by MAC-es/MAC-is in the RNC. 

Figure 27 shows the protocol model for the E-DCH transport channel with separate Controlling and Serving RNC. 
[FDD and 1.28 Mcps TDD - The protocol model in Figure 27 is applied for E-DCH configured for UEs in Cell_DCH.] 
In this case, the CRNC does not have any user plane RNL function for the E-DCH. MAC-es/MAC-is in SRNC is 
located directly above MAC-e/MAC-is in Node B, i.e. in the E-DCH user plane RNL, the SRNC is directly connected 
to the Node B, thus bypassing the CRNC user plane RNL. The CRNC performs only user plane TNL functions. 
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Figure 27: E-DCH: Separate Controlling and Serving RNC 

[FDD and 1 .28 Mcps TDD - Figure 28 shows the protocol model for the E-DCH transport channel configured for UE in 
CelLFACH for CCCH transmission. 

The E-DCH MAC (MAC-i/MAC-is) entity in the UE transfers MAC-i and MAC-is PDUs to the peer MAC-i in the 
Node B and and MAC-is entity in the CRNC. 

The E-DCH FP entity adds header information to form a E-DCH FP PDU that is transported to the RNC over a 
transport bearer.] 
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Figure 28: E-DCH configured for UE in Cell_FACH(CCCH case)(FDD and 1.28 IVIcps TDD only) 

[FDD and 1 .28 Mcps TDD - Figure 29 shows the protocol model for the E-DCH transport channel configured for UE in 
Cell_FACH for DCCH and DTCH transmission when the Controlling and Serving RNC are co-incident. 

The E-DCH MAC (MAC-i/MAC-is) entity in the UE transfers MAC-i PDUs to the peer MAC-i entity in the Node B 
and MAC-is PDUs to the peer MAC-is entity in the RNC using the services of the Physical Layer. 

The E-DCH FP entity adds header information to form anE-DCH FP PDU that is transported to the RNC over a 
transport bearer. 

An Interworking Function (IWF) in the Node B interworks the E-DCH frame received by the MAC-i entity into the E- 
DCH Frame Protocol (E-DCH FP) entity. E-DCH scheduling is performed by MAC-i in the Node B and reordering is 
performed by MAC-is in the RNC] 
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Figure 29: E-DCH configured for UE in Cell_FACH (DCCH/DTCH case) :Co-incident Controlling and 

Serving RNC (FDD and 1.28 Mcps TDD only) 

[FDD and 1 .28 Mcps TDD - Figure 30 shows the protocol model for the E-DCH transport channel configured for UE in 
CelLFACH for DCCH and DTCH transmission, with separate Controlling and Serving RNC. 

An Interworking Function (IWF) in the CRNC interworks the E-DCH data frame received from Node B into the lur E- 
DCH Frame Protocol (E-DCH FP) entity.] 
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Figure 30: E-DCH configured for UE in Cell_FACH (DCCH/DTCH case): Separate Controlling and 

Serving RNC (FDD and 1 .28 Mcps TDD only) 



12 UTRAN Performance Requirements 
12.1 UTRAN delay requirements 

Void. 
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Annex A (informative): 

SPID ranges and mapping of SPID values to cell reselection 

and inter-RAT/inter frequency handover priorities 

Ranges of SPID (Subscriber Profile ID for RAT/Frequency Priority) values, respectively Operator Specific and 
Reference values and the mapping at RNS of Reference SPID values to cell reselection and inter-RAT/inter frequency 
handover priorities are defined in TS 36.300 [35]. 
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Annex A2 (Informative): 
Deployment of Extended Identifiers 

A2.1 RNC Sizing Changes 
A2.1.1 U-RNTI Considerations 

The U-RNTI of 32 bits is normally divided in the following way: 



RNC-ID 12 bits 


S-RNTI 20bits 



Figure A2.1.1.1: RNC Side, normal split of U-RNTI in RNC-ID and S-RNTI 

When a large number of small RNCs were considered (HSPA+ cells), then extended RNC-ID was added, this took bits 
from the S-RNTI reducing this to 16bits thus: 



RNC-ID 16 bits 


S-RNTI 16bits 



Figure A2.1.1.2: RNC-Side, split of U-RNTI in RNC-ID and S-RNTI in the case of many small RNCs 

deployed 

Whilst this limited the S-RNTIs available to a RNC to 65k, as the RNCs were smaller this was acceptable, and allowed 
the addressing of 65k RNCs (per PLMN). 

Also related is the cell identity, containing the cell id and the RNC-ID 



RNC-ID 12 bits 


Cell id 16bits 



Figure A2.1.1.3: RNC Side, normal split of Cell identity in RNC-ID and Cell id. 

Or for extended RNC-ID 



RNC-ID 16 bits 


Cell id 12bits 



Figure A2.1.1.4: RNC Side, split of Cell identity in RNC-ID and CELL I in case of extended RNC-ID 

(many smell RNCs deployed) 

Rules are applied to handle extended RNC-ID in relation to the addressing of RNCs in Clause A2,2. 
For extending the S-RNTI to handle larger number of UEs. 
The UE side is unchanged: 



RNC-ID 12 bits 


S-RNTI 20bits 



Figure A2.1.1.5: UE Side, Normal split of U-RNTI in RNC-ID and S-RNTI 

The RAN side uses a shorter RNC-ID and extended S-RNTI to give 4x increase in the number of UEs that can be 
supported on a RNC. 
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RNC-ID 10 

bits 


S-RNTI 22bits 



Figure A2.1.1.6: UE Side, Split of U-RNTI in RNC-ID and S-RNTI in case of large number of UEs 

deployed. 

Rules and methods to achieve this extension are in Clause A2.1.2 and A2.1.3. 

A2.1 .2 Extend S-RNTI and reduce RNC-ID: Solution 1 

In this solution the S-RNTI is extended by 2 bits and the RNC-ID reduced by 2 bits. This gives an increased number of 
UE supported to 2'^22, but a reduced number of RNC-IDs available at 1024 (2'^ 10). 

UE Side 



RNC-ID 12 bits 


S-RNTI 20bits 



Figure A2.1 .2.1 : UE Side, Normal split of U-RNTI in RNC-ID and S-RNTI 



RAN Side 



RNC-ID 10 

bits 


S-RNTl 22bits 



Figure A2. 1.2.2: RNC Side, Extended S-RNTI and reduced RNC-ID ranges 

Although this approach increases by 4 the number of SRNTIs available, new rules are needed to handle addressing large 
RNCs with lObit RNC-IDs. It is also incompatible with extended RNC-ID. The co-existence of extended RNC-ID and 
extended S-RNTI in one network may not be possible or the rules would become exceedingly complex. 



Reallocation of U-RNTI to allow more S-RNTI 

Initially we look at the current restrictions in the standards. 

In TS25.331 Section 8.1.1.6.5 (System Information Block type 5 and 5bis), UE checks the 12bits of RNC-ID for 
performing URA update. Therefore the UE is using the 12bits of the RNC-Id in the U_RNTI to check for change in 
RNC and perform URA update. 

2> if the UE is in CELL_PCH or URA_PCH state: 

3> for FDD and for 1.28 Mcps TDD, if the UE supports HS-DSCH reception in CELL_PCH and URA_PCH 
state; and 

3> if IE "HS-DSCH paging system information" is included: 
4> if this IE is not currently stored; and 

4> if the value of the IE "SRNC identity" in the variable U_RNTI is not equal to the 12 MSBs of the 
received IE "Cell identity" in System Information Block type 3; and 
4> if the UE is in URA_PCH state: 

5> initiate the URA update procedure as specified in subclause 8.3.1, using the cause 
"periodic URA update". 

Due to this, RNC with Extended S-RNTI implementation would make sure to design the U-RNTI, to avoid unnecessary 
URA updates. This can be done by ensuring that the 2 MSB of the extended the S-RNTI are the same for UEs in the 
same area. 

A2.1 .3 Pooled RNCs: Solution 2 

In this solution a large RNC consists of 4 (or 2) RNCs each with a 12 bit RNC-ID. This could be considered a version 
of Solution 1, but here the large RNC is handled as a single RNC where the 2 LSBs of the RNC-ID are zero. 
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UE Side 



RNC-ID 12 bits 


S-RNTI 20bits 



Figure A2.1.3.1 : UE Side, Normal split of U-RNTI in RNC-ID and S-RNTI 



RAN Side 



RNC-ID 10 bits 


R 

X 


S-RNTI 20 bits 



Figure A2. 1.3.1 : RNC Side, RNC-ID split into extended RNC-ID and sub-RNC indicator. 

On the RAN side only the 10 MSBs are used for routing/addressing RNCs. Large RNC RNC-IDs are identified by RNC 
ID range and the 2 LSBs of RNC-ID being zero. CN routing and RNC routing would need updating to ensure that the 
mobility to the correct RNC occurs based on 10 bit RNC-ID. Other non-pooled RNCs will be routed in the normal way. 
This has perhaps more impact on the network than solution 1 but the large RNC would support the extended number of 
UEs, as it acts hke 4 RNCs. 

A2.2 RNC ID Extension 

The problem of insufficient RNC ID number space was identified and it was agreed to extend the range of the RNC ID. 
As a solution for the extension of the number space, it was agreed to increase the bit length of the RNC-ID from 12bits 
to 16bits by introducing a new ID with 16bits-length , and to introduce an Extended RNC ID IE into the relevant 
specifications. While the maximum number of RNCs within one PLMN in the ciuTent specification is 4096, the 
introduction of the new IE allows a maximum of 65536 (4096:legacy RNC ID + 61440: extended RNC-ID) RNCs to be 
deployed in one PLMN in the future. 

A2.2.1 Solution for RNC-ID Extension 

The Extended RNC-ID is only introduced into the network internal signalling specifications, e.g. RANAP between 
RNC and CN and does not require any changes to the RRC protocol so that legacy UEs can operate in an RNS which is 
configm-ed to use an extended RNC ID. 

This is possible by partitioning the 32bits of the U-RNTI in a different manner in RNS which is configured to use the 
extended RNC-ID. Thus some bits of the S-RNTI (20bits) part of the U-RNTI are used to extend the SRNC-ID part in 
the RNS using the extended RNC-ID. Therefore, the extension for the SRNC-ID in the network is not visible for the 
UE. As specified today, the UE always treats the 32 bit together as U-RNTI. 

UE Side 



SRNC identy 
12 bits 



S-RNTI 
20 bits 



RAN Side 



SRNC identy 
16 bits 


S-RNTI 

16 bits 



Figure A2.2.1.1 : Interpretation of U-RNTI in UE side and RAN side is configured 

to use the extended RNC ID 

As the same logic is applied for Cell Identity, 4MSB of the 16bit C-ID are used as an extension of RNC-ID. Thus under 
the RNC using the extended RNC-ID, the bits available for the C-ID are reduced to 12bits (4096). 
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UE Side 


SRNC identy 
12 bits 


Cell-ID 
16 bits 


RAN Side 


SRNC identy 
16 bits 


Cell-ID 
12 bits 



Figure A2.2.1.2: Interpretation of Cell identity (= UC-ID) in UE side and RAN side is configured 

to use the extended RNC ID 



The number of UEs and cells in one RNS using the extended RNC-ID are different from the one using the current RNC 
ID as shown in the table below since the 4bits used for the S-RNTI and Cell ID are used as part of extended RNC-ID in 
the RNS. 



The number of UEs in RNS 

The number of UEs for Inter-RAT HO 

at once in RNS 

The number of cells in RNS 



Current RNC-ID 

1 048 576 
1 024 

65 536 



Extended RNC-ID 

65 536 
64 

4 096 



A2.2.2 Rules for Configuration 

There are some limitations for configuring network when the extended RNC-ID scheme is used. The network 
configuration shall follow all four rules as stated below together. 

Explanation of terms 

Legacy RNC/CN: RNC/CN do not comprehend/support the extended RNC-ID IE/Scheme, e.g. Pre-Rel7 RNC/CN. 

Upgraded RNC/CN: RNC/CN comprehend/support the extended RNC-ID IE/Scheme and can distinguish which RNC- 
ID scheme are used in the received message or sending message based on the stored configuration data. 



Rulel): 



In case relocation needs to be supported to/from an RNC using the extended RNC-ID, it is recommended to 
connect the source and target RNCs to the same upgraded CN to reduce the number of upgraded CN. In case CN 
cannot be upgraded, it is recommended to use legacy RNC-ID under that CN. (Example in Figure A2.2.2.1). 



Rulel): 



Not configure the Iiu" interface connection between legacy RNC and upgraded RNC using the extended RNC-ID. 



Rule3): 



In case RNCs with legacy RNC-ID and RNCs with extended RNC-ID co-exist in the network, configure the 
legacy RNC-ID so that legacy RNC-ID will not be the same as the 12 bit of MSB of any of extended RNC-ID to 
which the legacy RNC may have lur connection. (See the Figure A2.2.2.3 and A2. 2.2.4). 

Rule4): 

In case a URA spanned over multiple RNCs with extended RNC-ID and the RNCs have different capability on 
HS-DSCH reception in URA_PCH state, the RNCs capable of HS-DSCH reception in URA_PCH state shall not 
have the same 12bit MSB in their extended RNC-ID compared to the RNCs not capable of HS-DSCH reception 
in URA_PCH. (See Figures A2.2.2.5 and A2.2.2.6). 

Depiction of Configuration Rules 
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RAN 1 and 4 with 12-bit 
RNC-ID 




Only CN #1 needs to be 
upgraded to understand 
16bit RNC-ID 



PS only RAN 2 and 3 with 16-bit 
RNC-ID 




Figure A2.2.2.1 : Configuration example for Rule 1 and 2 




RAN 1 and 4 with 12-bit 
RNC-ID 




CN #1 and CN #2 
need to be 
upgraded to 
understand 16bit 
NC-ID 



PS only RAN 2 and 3 with 16-bit 
RNC-ID 




Figure A2.2.2.2: Configuration example for Rule 1 and 2. 
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RNCA 

(Upgraded) 

RNC ID: 

OOB 



RNC-ID Table: 
RNC1: OOB 

eHSPANB1:00B1 
eHSPA NB3: 00A1 




eHSPA 
Node B1 
RNC ID: 

00B1 



Cell/URA Update 
U RNTI:00B1xxxx 



SRNC-ID: OOB 
S-RNTI:1xxxx 

Figure A2.2.2.3: Problematic configuration example 
(does not follow RuleS) 




eHSPA 

Node B3 

RNC ID: 00A1 


o 


S 



RNC-ID Table: 
RNC1: OOB 

eHSPA NB3: 00A1 




eHSPA 

Node B2 

RNC ID: 00A2 



Cell/URA Update 
U RNTI:00B1xxxx 



No lur and not neighbouring 



No case that UE anchored by 
eHSPA Node 81 moves to 
cell under the Node B2 



eHSPA 
Node B1 
RNC ID: 

GOBI 



SRNC-ID: OOB 
S-RNTI:1xxxx 



X 



SRNC-ID: OOB 
S-RNTI:1xxxx 



Figure A2.2.2.4: Configuration example for RuleS 
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eHSPA Node B1 

RNC ID 00A1 

Capable of 

Enhanced-FACH 



_ Paging _ 
Request 



eHSPA Node B2 

RNC ID 00A2 

Non Capable of 

Enhanced-FACH 
SRNC for UE1 



_ Paging . 
Request 



eHSPA Node B3 

RNC ID 00A3 

Capable of 

Enhanced-FACH 




UE does NOT send URA 
Update 



Figure A2.2.2.5 Problematic configuration example (does not follow Rule4) 



eHSPA Node 81 

RNC ID 00A1 

Capable of 

Enhanced-FACH 



(Paging Request — 



eHSPA Node B2 

RNCID00B1 

Non Capable of 

Enhanced-FACH 



— Paging Request^ 



eHSPA Node 83 

RNC ID 00A2 

Capable of 

Enhanced-FACH 




Figure A2.2.2.6 Configuration example for Rule4 



A2.2.3 Configuration Example 

The RNC ID configuration example below is following the rules listed in A2.2.2 and showing the configuration in 
Figure A2.2.2.2 in a large scale. 
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Overlay cell 




Non-Overlay 
cell 



RNC_C 
OOA 

(Upgraded) 



Figure A2.2.3.1 : Valid RNC ID Configuration Example 
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